Numerous methods and techniques are conventionally known for encrypting data or information, including methods and techniques for encrypting data in a database. Database data encryption may represent the more challenging situation because of the large volume of data that may be stored in the database, the need to access or query such data, and the advantages or requirements for speed of access or query that may usually require encryption and/or decryption.
One of the most common conventional methods involves or requires modification of the application or applications that store, manipulate, query, and/or display the data. In this situation, the application may usually be need to be rewritten, modified or changed to call a particular Application Program Interface (API) to a cryptographic services provider that will provide the encryption and/or decryption services. The cryptographic services provider may typically be a software library, an interface to a cryptographic accelerator card, or an interface to a Hardware Security Module (HSM), which may both store keys and accelerate cryptographic operations. One well known example of such an API is the PKCS#11, a cryptographic token interface standard, which provides a generic interface to Hardware Security Modules.
This PKCS#11 standard specifies an API, called Cryptoki, to devices which hold cryptographic information and perform cryptographic functions. The Cryptoki API, follows a simple object-based approach, and attempts to address the goals of technology independence (any kind of device) and resource sharing (multiple applications accessing multiple devices), presenting to applications a common logical view of the device called a cryptographic token. Security and cryptographic standards change and evolve, and this PKCS#11 standard is referenced for purposes of and example, and is not a limitation of the invention or embodiments thereof.
In some limited instances, it is possible to provide a transparent mechanism for securing data. A transparent mechanism is a mechanism which does not require application program modifications or changes, such as discussed above.
One possible way of doing this for data which resides in certain types of databases is described in co-pending U.S. patent application Ser. No. 11/236,061 filed 26 Sep. 2005, entitled “Transparent Encryption Using A Secure Device” naming inventors Brian Metzger. Stephen Mauldin. Bruce Sandell, and Jorge Chang, and assigned to the same assignee as the present application is assigned. Ingrian Networks. Inc. (Redwood City, Calif. USA): which application is incorporated by reference. Alternatively, and at a lower level, it is also possible to encrypt a file, directory, or file system transparently such as is described in co-pending U.S. Provisional Patent Application No. 60/897,802 filed 26 Jan. 2007, entitled “Secure File Encryption System And Method”, and assigned to the same assignee as the present application is assigned. Ingrian Networks. Inc. (Redwood City. Calif. USA); which application is incorporated by reference. The first of these applications describes a transparent mechanism for securing data and takes advantage of certain facilities in the various popular databases, especially in the Database Management System (DBMS), known as an “Instead of” trigger, which allows a view to be updatable even though in the definition of the view, UDFs are called. The second application makes use of functionality called filter drivers, which are essentially a hook in the file system to allow data to be modified as it moves in and out of the file system. This latter invention takes advantage of technology and software designed by Ingrian Networks, Inc. to work on a level closer to hardware—the so-called driver level.
Unfortunately, the ability to provide such a transparent mechanism may usually rely on the provision of certain facilities necessary to take advantage of either of the two previously mentioned transparent encryption methods. B way of example, the transparent encryption of databases solution referred to in the above referenced patent application, advantageously makes use of a piece of functionality which may be found in some but not in all databases called “Instead of” triggers. At least some of these so called “Instead of” triggers are a facility for allowing a view to remain updatable even though its definition contains references to UDEs (used to encrypt and decrypt data). These so-called “Instead of” triggers may also be likened to sets of actions defined by an application to run instead of updating of inserting a field into a row of a database table. Since the solution for transparent encryption of databases makes use of views, and requires that at least some of these views be updatable while also containing references to UDFs, this functionality is necessary for operation.
One database in widespread commercial use is the IBM DB2 database. The IBM DB2 database running in the Z/OS operating system environment is an example of a database system that does not support such “Instead of” triggers. Therefore conventional methods and techniques, including those described above, may not be entirely applicable or satisfactory, when applied to the IBM DB2 database on Z/OS, or to databases having the same limitations, whether running in a Z/OS operating system or other operating system environment.
There are also problems and limitations when applying cryptographic functions transparently to other stored data when such data is not in the form of a traditional database, and development of driver-level encryption proves to be impossible or impractical.
Therefore, there remains a need to provide transparent cryptographic functions, including one or both of encryption functions and decryption functions (usually both of these) to be applied to data stored by some operation or mechanism, including but not limited to data stored in a formal or conventional database. More particularly, there remains a need to provide transparent cryptographic functions, for data stored in the IBM DB2 database or similar databases having running in the IBM Z/OS operating system or other operating system presenting similar or analogous limitations relative to support of user-defined triggers, hooks, and functions.